Automated transaction machines are known in the prior art. Automated transaction machines are used to electronically carry out transfers representative of value. Automated transaction machines include for example, cash dispensers, ticket dispensers, scrip dispensers, gaming machines, Automated Teller Machines (ATMs) and other self service terminals. For purposes of convenience all such automated transaction machines will be referred to herein as ATMs unless otherwise specifically indicated.
ATMs may include various types of transaction function devices. These devices are operated to carry out transactions. Different types of ATMs include different types of devices. The different types of devices enable the ATM to carry out different types of transactions. For example, some types of ATMs include a depository for accepting deposits while other ATMs do not. Some ATMs have a “touch screen” while others have separate displays and input buttons. ATMs can also be fitted with devices such as cash and coin acceptors, statement printers, check validators, bill acceptors, thumb print readers and other types of devices, while other ATMs do not include such devices. ATMs also continue to incorporate improved or additional features. For example, printers are improved from black to color inks; cash acceptors are improved to work with both old and new styles of a twenty-dollar bill; and card readers are improved so they can work with magnetic stripe cards and smart cards.
As long as the basic functionality of a new device is the same as a device it replaces, the software code or drivers needed to communicate with the new device may also remain generally the same. Thus for example the application software for an ATM with a cash dispenser can issue a command to dispense cash as it has always done even after the cash dispenser is improved.
However, if the new device is so substantially changed relative to a device that it replaces so that it requires an updated driver, a service technician will be required to install a new device driver with the new device. As long as the new driver is backward compatible with the older driver, the ATM will continue to function generally as before.
Unfortunately installing new drivers can require more time than installing a new physical transaction function device in the ATM. Normally new drivers are installed from a floppy disk, CD ROM or other portable storage medium. A technician is required to access the computer that runs the ATM, and must replace the physical files of the old drivers with the new drivers. Even when user friendly setup programs or wizards are used to make this process easier, it requires a degree of specialized knowledge and expertise to update the ATM software driver correctly.
For example, a single type of device may have a different driver for each model and version that has been manufactured. Keeping track of the correct drivers and verifying that the correct driver is installed for a device, is a tedious endeavor. Furthermore it may not be obvious when a driver for “Model A” of a device is incorrectly used for “Model B”. Although 99% of the functionality of the device may work properly, an ATM with an incorrect driver may experience intermittent problems related to that 1% of incompatibility with the driver.
Tracking down these incompatibilities can consume a large amount of a technician's time. Consequently it would be desirable to streamline the updating of drivers to reduce the amount of time it takes to update a device and to reduce the chances of installing the incorrect driver for a new device.
A typical ATM application program not only communicates through an interactive user interface with input and output devices, but also controls the overall functionality of the devices in an ATM. Prior art ATMs generally require that the ATM be shut down when a new or additional device is installed. Prior art systems assume that individual devices that are configured for use in the ATM will remain available while the ATM is operating. However, if a device is disabled, prior art ATMs may not notice that the device is disabled until the ATM attempts to use the device, at which time an error is generated. Such an error usually results in the entire ATM or system being disabled until the device is reenabled or the ATM is manually reconfigured to know that the device is no longer available.
Consequently, changes to the configuration of an ATM require disabling the ATM for a period of time to remove, replace or add a device. This process can be time consuming and may result in lost business at the ATM. Consequently it would be desirable for an ATM to have the ability to detect when devices are present or not present and to automatically change configuration while continuing to operate.
Often functions of a device in an ATM are directly controlled responsive to inputs to a user interface. Individual devices often do not control the functionality of other devices. For example, when an ATM application program needs to lock or unlock a device which contains envelopes and also needs to enable a device which accepts deposit envelopes, the application must issue commands to both devices. This is the case even though both devices are related and are designed to operate at proximate times. Individual ATM transaction devices often do not communicate with each other. For example, a device for receiving deposit envelopes does not issue a command to the envelope holder to close the door to the holder when the deposit function is completed. The application program must generally include all the programming logic for coordinating the operation of multiple devices. The additional code required makes the application program more complex and more difficult to modify. Consequently it would be desirable for ATM devices to communicate directly with each other to facilitate the performance of coordinated activities by transaction function devices.
Prior art device drivers for devices in an ATM are often composed of low level functions for controlling the hardware. Programmers who create ATM software are generally required to have a high degree of knowledge about how a hardware device and device drivers are designed to work before the device can be incorporated into an ATM. This low level complexity often makes ATM application programs more complex and difficult to produce and reconfigure. Consequently it would be desirable to increase the efficiency of programmers who develop ATM software and to make device drivers easier for programmers to integrate into an ATM program without requiring the programmer to have an in-depth understanding of the low level hardware.
Many types of ATMs include an internal device bus to which transaction devices are attached. This device bus facilitates the communication between the application program and the individual devices. Such device buses are often proprietary and are designed to connect directly with the computer that controls the operation of the ATM. Such device buses limit the number of devices that can be attached to an ATM and limit the physical locations at which devices can be attached. Consequently, it would be desirable to have an ATM with a system for attaching devices that is not limited to the physical constraints of an internal bus.